Systems and methods for facilitating transactions between payers and merchants

ABSTRACT

A computer-implemented method for facilitating a transaction between a payer and a merchant comprises identifying one or more merchants that are at or in proximity to a geolocation of the payer, and providing the payer a reward, notification or a reminder of a stored value associated with a merchant to apply to a transaction with the merchant. The reward, notification or reminder of the stored value can be provided based on an inference of intent of the payer to conduct a transaction with the merchant. A request to conduct a transaction with the merchant is received from the payer. The transaction between the payer and the merchant is processed with the reward or stored value applied thereto. A notification can be sent to the payer alerting the payer to a discounted item or proximity of the payer to an item and/or merchant they have saved to a list.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/886,228, filed Feb. 1, 2018, which is a continuation of U.S. patentapplication Ser. No. 13/951,410, filed Jul. 25, 2013, which claims thebenefit of U.S. Provisional Application No. 61/733,394, filed Dec. 4,2012; both of which are incorporated herein by reference in theirentireties.

BACKGROUND

Consumers routinely make purchases using plastic credit or debit cards.Such plastic cards typically have magnetic stripes or chips that areencoded with information, such as a consumer's account information. Acredit or a debit card may be used in a business transaction with a bankor creditor through use of a device that communicates with the bank orcreditor, such as, for example an automated teller machine (ATM) or acredit card reader.

Credit cards having standard specifications can typically be read bypoint-of-sale devices at the location of a merchant. When the card iscoupled to an electronic card reader at the merchant, such as a platformcard reader, the electronic card reader may use its built-incommunications interface to contact a creditor that handles creditauthentication requests to process the transaction. The transaction maybe finalized upon verification of the consumer's account information andthe receipt of an approval signal from the creditor.

SUMMARY

This disclosure provides systems and methods for facilitatingtransactions between payers and merchants. Payers in some cases can beincentivized to conduct a transaction with a merchant. In some examples,a payer can be provided a reward or a reminder of a stored valueassociated with the merchant to apply to a transaction with the merchantbased on an inference of intent of the payer to conduct a transactionwith the merchant. The intent can be inferred based on variouspayer-specific factors, including a transaction history of the payer.

An aspect of the disclosure provides a computer-implemented method forfacilitating a transaction between a payer and a merchant, comprisingdetermining a current context of the payer based on a current time orlocation data from a device of the payer, and providing the payer with areminder of a stored value associated with the merchant. The reminder isprovided based on the current context of the payer. Next, request for atransaction between the payer and the merchant is received by a computersystem programmed to facilitate the transaction. With the aid of acomputer processor of the computer system, the transaction between thepayer and the merchant is processed. The stored value is applied to thetransaction.

Another aspect of the disclosure provides a computer-implemented methodfor facilitating a transaction between a payer and a merchant among oneor more merchants, comprising identifying the one or more merchants thatare at or in proximity to a geolocation of the payer, and providing thepayer with a reward or a reminder of a stored value associated with themerchant to apply to a transaction with the merchant. The reward or thereminder is provided based on an inference of intent of the payer toconduct a transaction with the merchant or purchase goods or servicesprovided by the merchant, which inference of intent is calculated withthe aid of a computer processor. Next, a request from the payer toconduct a transaction with the merchant is received. The request isreceived by a computer system programmed to facilitate the transaction.With the aid of a computer processor of the computer system, thetransaction between the payer and the merchant is processed. The rewardor the stored value is applied to the transaction or maintained for usein a future transaction.

Another aspect of the disclosure provides a computer-implemented methodfor providing a reward to a payer in connection with a transactionbetween the payer and a merchant, comprising processing, with the aid ofa computer processor of a computer system programmed to facilitate atransaction between a payer and a merchant, the transaction between thepayer and the merchant. The transaction is initiated upon receiving, bythe computer system, a request from the payer to conduct a transactionwith the merchant. The request can be received upon the computer systemproviding the payer a reward or a reminder of a stored value associatedwith the merchant to apply to the transaction or a future transaction.The reward or reminder of the stored value can be provided to the payerbased on an inference of intent of the payer to conduct a transactionwith the merchant.

Another aspect of the disclosure provides a computer-implemented methodfor facilitating a transaction between a payer and a merchant,comprising providing the payer a reward or a reminder of a stored valueassociated with the merchant to apply to a transaction with themerchant. The reward or reminder of the stored value is provided basedon a determination, with the aid of a computer processor of a computersystem, of the likelihood of the payer to conduct a transaction with themerchant among one or merchants at or in proximity to a geolocation ofthe payer. The transaction between the payer and the merchant isprocessed with the aid of the computer system subsequent to the payerbeing provided the reward or the reminder of the stored value.

Another aspect of the disclosure provides a system for facilitating atransaction between a payer and a merchant, comprising one or morecomputer processors, and a memory location coupled to the one or morecomputer processors. The memory location comprises machine-executablecode which, when executed by at least a subset of the one or morecomputer processors, implements any of the methods described above orelsewhere herein.

Another aspect of the disclosure provides a computer-readable mediumcomprising code which, when executed by one or more computer processors,implements any of the methods described above or elsewhere herein.

Additional aspects and advantages of the present disclosure will becomereadily apparent to those skilled in this art from the followingdetailed description, wherein only illustrative embodiments of thepresent disclosure are shown and described. As will be realized, thepresent disclosure is capable of other and different embodiments, andits several details are capable of modifications in various obviousrespects, all without departing from the disclosure. Accordingly, thedrawings and description are to be regarded as illustrative in nature,and not as restrictive.

INCORPORATION BY REFERENCE

All publications, patents, and patent applications mentioned in thisspecification are herein incorporated by reference to the same extent asif each individual publication, patent, or patent application wasspecifically and individually indicated to be incorporated by reference.

BRIEF DESCRIPTION OF DRAWINGS

The novel features of the claimed invention are set forth withparticularity in the appended claims. A better understanding of thefeatures and advantages of the present invention will be obtained byreference to the following detailed description that sets forthillustrative embodiments, in which the principles of the invention areutilized, and the accompanying drawings or figures (also “FIG.” or“FIGs.” herein) of which:

FIG. 1 schematically illustrates a transaction workflow, in accordancewith an embodiment of the invention;

FIG. 2 schematically illustrates a transaction workflow in which areward or a stored value (e.g., a gift card or prepaid balance) isapplied to a given transaction, in accordance with an embodiment of theinvention;

FIG. 3 schematically illustrates a merchant directory with merchantcards, in accordance with an embodiment of the invention;

FIG. 4 schematically illustrates a system for facilitating methods ofthe disclosure; and

FIGS. 5-7 show screenshots of graphical user interfaces (GUI's) ofapplications (apps) implemented on an electronic device, in accordancewith various embodiments of the invention.

DETAILED DESCRIPTION

While various embodiments of the invention have been shown and describedherein, it will be obvious to those skilled in the art that suchembodiments are provided by way of example only. Numerous variations,changes, and substitutions may occur to those skilled in the art withoutdeparting from the invention. It should be understood that variousalternatives to the embodiments of the invention described herein may beemployed.

The term “merchant,” as used herein, generally refers to an individual,business or other entity, the occupation of which is the sale of goodsor services for profit or, alternatively, trade of an item of value foranother item of value. In an example, a merchant is a retail business ora shopkeeper. A merchant can be a provider of good, services, or bothgoods and services. A merchant may be an online business or entityoffering a product or service for profit of trade. Examples of merchantsinclude, without limitation, food stores, grocery stores, electronicstores, department stores, bars, clubs, restaurants and book stores.

The term “user,” as used herein, generally refers to an individual orentity that uses systems and methods of the disclosure. A user can be anindividual or entity that wishes to purchase a product or service of amerchant. A user can be a payer. A user that is a payer can potentiallyconduct a transaction with a merchant, but need not necessarily conducta transaction with the merchant. In some situations, a user can be amerchant.

The term “stored value,” as used herein, generally refers to an item ofvalue to a payer. Examples of stored values include gift cards, prepaidbalances, or balances from previous transactions, such as merchantcredit (e.g., store credit).

The term “widget,” as used herein, is an element in an application orweb page that includes dynamic content. Widgets can take the form ofon-screen device (clocks, event countdowns, auction-tickers, stockmarket tickers, flight arrival information, daily weather etc.).

The term “geographic location” (also “geo-location” and “geolocation”herein), as used herein, generally refers to the geographic location ofan object, such as a user. A geolocation of a user can be determined orapproximated using a geolocation device or system associated with theuser, which may be an electronic device (e.g., mobile device) attachedto or in proximity to the user. Geolocation information can include thegeographic location of the object, such as coordinates of the objectand/or an algorithm or methodology to approximate or otherwise calculate(or measure) the location of the object, and, in some cases, informationas to other objects in proximity to the object. In some examples,geolocation information of a user includes the user's geographiclocation and/or the location of one or more merchants in proximity tothe user. Geolocation information can include the relative positioningbetween objects, such as between users, or a payer and a merchant. Insome cases, the geolocation of an object (e.g., user, electronic device)is not necessarily the location of the object, but rather the locationthat the object enters an area or structure, such as a building.

A geolocation device may be a portable electronic device (e.g., Apple®iPhone®, Android® enabled device). In some cases, the geolocation of anobject can be determined using the manner in which a mobile deviceassociated with the object communicates with a communication node, suchas a wireless node. In an example, the geolocation of an object can bedetermined using node triangulation, such as, e.g., wireless node, WiFinode, satellite triangulation, and/or cellular tower node triangulation.In another example, the geolocation of a user can be determined byassessing the proximity of the user to a WiFi hotspot or one or morewireless routers. In some cases, the geolocation of an object can bedetermined using a geolocation device that includes a global positioningsystem (“GPS”), such a GPS subsystem (or module) associated with amobile device (e.g., GPS capabilities of an Apple® iPhone® or Droid®based system).

In some situations, the geolocation of an object can be determined withthe aid of visual and/or audio information captured by an electronicdevice of a user, such as, for example, images and/or video captured bya camera of the electronic device, or a peripheral device (e.g., Google®Glasses) coupled to the electronic device.

Methods for Inferring Intent

An aspect of the disclosure provides methods for inferring payer intentto conduct a transaction with one or more merchants or one or moregroups of merchants. Such methods can be implemented with the aid of acomputer system (“system”) programmed or otherwise configured to inferintent, as described elsewhere herein. The user can be a payer, such asa payer engaging or seeking to engage in a product or servicetransaction with a merchant. Inferred intent can be used to recommend orotherwise suggest one or more merchants to a payer, and/or make productor service recommendations to the payer. For instance, if a system ofthe disclosure determines a likely (e.g., more likely than not) intentof a payer, then the system can recommend a product or service to thepayer with a reasonable expectation that the payer will select theproduct or service.

In some examples, the system determines whether the payer intends to oris likely to conduct a transaction with a merchant, and the systemprovides the payer with a reminder or prompt displaying a reward (e.g.,discount, promotion, or deal) or a stored value (e.g., a gift card or aprepaid balance) that can be applied to the transaction with themerchant. The system can provide the reward as an offer for a freeproduct or service, or a product or service discount. The reward orstored value can be applied to a present transaction with a merchant, orapplied to a future transaction with a merchant.

The reward or stored value can be provided to incentivize the payer tovisit the merchant and conduct the transaction with the merchant,thereby increasing the likelihood that the payer conducts thetransaction with the merchant. The reward can be one or more freeproducts and/or services, one or more product and/or service discounts,or other incentive (e.g., gift) to the payer to conduct a transactionwith the merchant.

Payer intent can be directed to a present intent to make a purchase. Asan alternative, payer intent can be directed to a future intent to makea purchase. In some situations, payer intent can be directed to theinclination or propensity of the payer to select a product or serviceamong a plurality of products presented to the payer. Payer intent canbe directed to the inclination or propensity of the payer to select amerchant among a plurality of merchants. For example, a payer may nothave a present intent to visit a coffee shop, but the system, from thepayer's previous coffee shop purchases, may infer that the payer willwish to purchase from a given coffee shop among a plurality of coffeeshops in a geographic area.

Payer intent can be directed to a merchant with whom the payer may wishto conduct a transaction or a product (or service) that the payer maywish to purchase. Alternatively, payer intent can be directed to amerchant or product that is deemed (e.g., by systems of the disclosure)to be most likely selected by the payer, such as from multiple merchantsand/or products or services. As another alternative, payer intent can bedirected to a merchant or product (or service) that is deemed to beselected by the payer within a given degree of likelihood when presentedto the payer, such as selected by the payer at a degree of likelihood ofat least about 5%, 10%, 20%, 30%, 40%, 50%, 60%, 70%, 80%, 90%, 95%, or99%. In an example, the system can determine that a payer is at least51% or 60% likely to select a given merchant from a plurality ofmerchants at or in proximity to the payer.

In some examples, a reward or reminder of stored value associated with amerchant is provided to the payer if the system determines that thepayer is at least about 5%, 10%, 20%, 30%, 40%, 50%, 60%, 70%, 80%, 90%,95%, or 99% likely to conduct a transaction with a given merchant. Thereward can be directed for use with the given merchant. In otherexamples, a reward is provided to the payer if the system determinesthat the payer is at least about 5%, 10%, 20%, 30%, 40%, 50%, 60%, 70%,80%, 90%, 95%, or 99% likely to purchase a product or service from themerchant.

Payer intent to conduct a transaction with a merchant can be calculatedor otherwise determined from various factors, such as the payer'shabits, user preferences, and payer contextual data (collectively “payerdata” herein). The payer's habits and preferences can be inferred fromsources, such as a travel history of the payer, a work history of thepayer, an educational history of the payer, a health history of thepayer, a consumption history of the payer, a transactional (e.g.,spending) history of the payer, and social engagement(s) history of thepayer (collectively, “payer history” herein). Payer intent can also bederived by collections that the payer stores within the system. Forinstance the payer may collect a list of their favorite restaurants or alist of items they are interested in purchasing, which can be similar toa grocery list. The list can be prepared ahead of time, or the payer cancreate the lists while the payer is at a location (e.g., store) of themerchant, such as by, for example, scanning bar codes in order toremember the product for future purchase and receive reminders, such aswhen the product is discounted. Payer intent can be inferred from payerhistory, which can be retained by the system in a computer database. Forexample, the system can maintain a database with a transactional historyof the payer, which can include a history of transactions between thepayer and one or more merchants.

In some examples, a payer can create a product list. A product list caninclude items the payer knows that the payer may want or one or moreitems that the payer selects from a merchant, such as when the payervisits the merchant. The system can then identify when the payer shouldbe informed that a particular item from the payer's list is in proximityto the payer. In an example, the payer has a soap on a product list ofthe payer and the system determines if a particular merchant sells thesoap. The system can perform a search using, for example, naturallanguage processing to determine whether the merchant sells the soap, inaddition to determining other items that the merchant sells which may beof desired or of interest to the payer.

Payer contextual data can be based on, for example, time data (e.g.,time of day, day of week, etc.), calendar data (e.g., data reflectingpast and future time and location for events) or payer device data(e.g., location of the device) that reflects a payer's context at agiven point in time. A combination of payer context data and/or payerhistory data and/or payer list data can be used to surface relevantrecommendations, or prompts for reward or stored value. In an example,the system determines that a payer (e.g., customer) has stored valuewith a nearby merchant and that the payer is near that merchant. Thesystem can provide a reminder to the payer that he/she has stored valuewith the merchant. For example, the payer can have a gift card with acoffee shop. The system can remind the payer of the gift card when thepayer is nearby the coffee shop. In another example, the system candetect deviations from patterns in the payer history, determine that thecontext for the payer has changed, and provide recommendations asappropriate. By way of example, the system uses payer history todetermine that the payer usually buys coffee and bagel in the morning.The system can determine based on location data that the payer is not athome, but on a business trip, and suggest merchants nearby that sellcoffee and bagel. The system can also detect when the payer is near anitem or merchant the payer has saved to the payer's list, or near itemssimilar to items on the payer's list. By way of example, the systemknows that the payer has saved a bottle of aspirin to the payer's listand the system alerts the payer when the payer is in proximity to amerchant that has a discounted bottle of aspirin.

The payer history can be gleaned or otherwise collected (or aggregated)from various sources, such as, for example, network sources, including,without limitations, Internet and intranet sources. The system can beconfigured to search various network sources (e.g., web sites) andretrieve and save information that may qualify as information includedin the payer history. In some examples, the system can aggregateinformation of or related to payer history from various network sources,including social networking web sites (e.g., Facebook®, Foursquare®,Google+®, Linkedin®, Tumblr®, Instagram®, Pinterest®) or on publishersites, such as, for example, weblogs (e.g., Facebook®, Tumblr®).

In some examples, the system includes a web crawler that constantly,routinely or periodically collects payer history information and storesthis information in a database of the system. The payer historyinformation can then be used to predict an intent or likelihood of thepayer to conduct a transaction with a merchant.

Payer intent to conduct a transaction with a merchant can be calculatedby using payer data (e.g., such as payer history, payer contextual dataand lists of items curated by the payer) and predicting a likelihood ofthe payer to conduct the transaction with the merchant. The predictioncan use various mathematical models to calculate a likelihood of thetransaction. The prediction can make use of multivariate statistics toidentify classes of similar subjects in a sample population to build amodel that provides or approximates a predictive spending pattern of apayer. Techniques that can be employed include, but are not limited to,Collaborative Filtering, Machine learning, Natural Language Processing,Discriminant Function Analysis (DFA), Hierarchical Clustering Analysis,Factor Analysis (in which an underlying model or relationship isassumed), Self-Organizing Maps (SOMs), Support Vector Machines (SVMs),and Neural Nets. Each can be a pattern recognition technology usingmultivariate descriptor vectors, which subjects are classmates, to morecompletely manage an adaptive clinical trial.

In some cases, a predictive spending model of a payer can be used toassess a likelihood (or intent) of the payer to conduct a transactionwith a merchant among a plurality of merchants. Based on the likelihood,the system can provide (or offer) the payer a reward to apply to thetransaction or a future transaction. The reward can be intended toincrease the likelihood that the payer will conduct a transaction withthe merchant.

For example, if the system determines that the payer is 50% likely toconduct a transaction with a first coffee shop and 80% likely to conducta transaction with a second coffee shop, the system can offer the payera reward or remind the payer of a stored value that can be applied in atransaction with the second coffee shop (e.g., “Hi Jack, you have $5unused credit at the Coffee Spot”). Alternatively, the system can offerthe payer a reward to apply to a transaction with the first coffee shopif the system determines that the payer, with the reward, is more likelyto conduct a transaction with the first coffee shop than the secondcoffee shop with or without the reward.

Inference of intent can be determined from a predictive spending model.The model can include assessing a trajectory of payer spending withtime. For example, the spending habit of the payer can be recorded withtime and used to predict which merchant the payer is likely to elect toconduct a transaction at a given point in time. In some cases, thepredictive spending model can be used to predict a product or servicethat the payer will likely purchase.

The predictive model can include sample payer information longitudinallyacross time for the payer, or sampling payer information longitudinallyacross multiple payers. The latter scenario can provide group spendinginformation, which can aid in predicting which merchant a group ofpayers is likely to select among multiple merchants.

In some situations, payer intent can be inferred by determining acurrent context of the payer. The current context of the payer can bedetermined based on a current time and/or location (e.g., geolocation)of the payer, which time and/or location can be determined using adevice (e.g., geolocation device) of the payer. In some examples, payerintent is calculated by correlating, using a computer processor, timedata (e.g., timestamp) and/or location data of the payer with timeinformation and/or location information associated with known contextsof the payer and/or others users. In some cases, the correlation is madewith the of a context table having context categories (e.g., work,baseball game, social event) as a function of time and/or location. Thecontext table can be populated through user input, such as input by thepayer and other payers.

Methods for Facilitating Transactions Between Payers and Merchants

In an aspect of the disclosure, a computer-implemented method forfacilitating a transaction between a payer and a merchant comprisesidentifying one or more merchants that are at or in proximity to ageolocation of the payer, and providing the payer a reward or a reminderof stored value that can be applied to a transaction with the merchant.The reward or reminder of stored value can be provided for applicationto a transaction between the payer and a merchant among the one or moremerchants, or applied to a transaction with another merchant. The rewardor reminder of stored value can be provided based on an inference ofintent of the payer to conduct a transaction with the merchant. Forexample, the award can be provided based on a likelihood (e.g., at least60%) that the payer will want to conduct a transaction with themerchant.

In some cases, a current context of the payer can be determined based ona current time and/or location data (e.g., geolocation data) from adevice of the payer. A reward, discount, alert or reminder of storedvalue can be provided based on the current context of the payer.

Next, a request from the payer enter into a transaction with themerchant is received. The request can be received by a computer systemprogrammed to facilitate the transaction, as described elsewhere herein.The transaction between the payer and the merchant is the processed withthe aid of a processor of the computer system. The reward or storedvalue is applied to the transaction or maintained for use in a futuretransaction.

For instance, the reward or stored value can be applied to the presenttransaction between the payer and the merchant. That is, the reward orstored value can be applied to the transaction that the payer hasrequested to conduct with the merchant. As an alternative, the reward orstored value can be applied to a future transaction between the payerand the merchant or another merchant. The period in which the award canbe applied can be selected by the system or the merchant. For instance,the aware may be redeemable within a period of 1 minute, 1 hour, 2hours, 3 hours, 4 hours, 5 hours, 6 hours, 12 hours, 1 day, 2 days, 3days, 4 days, 5 days, 6 days, 1 week, 2 weeks, 3 weeks, 1 month, 12months, 1 year, or more.

In some cases, the request to conduct the transaction with the merchantcan be received from an electronic device of the payer, such as aportable electronic device. The portable electronic device can include auser interface (UI), such as a graphical user interface (GUI), which canenable the payer to initiate the transaction between the payer and themerchant and to view details of the reward, as well as any promotionsoffered by the merchant to the payer.

The electronic device can be a geolocation device. The geolocation ofthe payer can be determined with the aid of the geolocation device. Insome examples, the request to conduct the transaction with the merchantcan be received from the geolocation device.

The inference of intent can be calculated with the aid of one or moreprocessors. The inference of intent is calculated with the aid of aprocessor of the computer system. In some examples, the inference ofintent is calculated by a probabilistic determination that the payer isgoing to purchase a given product or service, or visit a given merchant.This determination can be made by accessing a database of the computersystem or another computer system in communication with the system, andreviewing a transaction history or other behavioral pattern or historyof the payer.

In some cases, the inference of intent is calculated based uponpayer-specific information maintained in a database of the computersystem. The payer-specific information can be selected from one or moreof a transaction history of the payer, a travel schedule of the payer, awork schedule of the payer, an eating history of the payer, a spendinghistory of the payer, and social engagement(s) history of the payer.

The request to conduct a transaction with the merchant can be receivedfrom an electronic device of the payer. The electronic device can be aportable electronic device, such as a Smart phone (e.g., Apple® iPhone,Android-enabled telephone), tablet PC (e.g., Apple® iPad, Samsung®Galaxy Tab), or laptop computer (e.g., Apple® MacBook Pro, Dell®Laptop).

The reward or stored value can be maintained in a database, which can belocated on the computer system or other system in communication with thecomputer system. In some cases, upon the computer system receiving therequest from the payer to conduct a transaction with the merchant, thedatabase is accessed to identify the reward or stored value that can beused with the merchant. Alternatively, the computer system accessesdatabase to identify the reward or stored value prior to the payerrequesting to conduct a transaction with the merchant. For instance, therewards database can be accessed to identify the reward if the computersystem determines that the payer has an appreciable likelihood (e.g.,more likely than not, or a probability of at least 50%, 60%, 70%, 80%,or 90%) of conducting the transaction with the merchant.

A reward or stored value can be selected by the computer system or themerchant to be specific to the payer. For example, the computer systemcan determine that the payer prefers a first product over a secondproduct and provide a reward directed to the first product (e.g., adiscount on the first product).

In some examples, upon the completion of processing of the transactionbetween the payer and the merchant, the database can be updated. Thedatabase can be updated with a record of the transaction and the rewardor stored value that was applied to the transaction. In some examples,the computer system displays on an electronic device of the payer thestatus of the reward based upon the update.

In some situations, the availability of a reward for use is milestonedependent. The computer system can apply the reward to the transactionif the computer system determines that the milestone has been met. Themilestone can be, for example, a minimum number of product or servicepurchases from the merchant, or a spending limit for a giventransaction. The reward in such a case can aid the payer to meet a givenmilestone for the reward.

In some examples, once the one or more merchants in proximity to thepayer are identified, a list of the one or more merchants is provided tothe payer. The list can be provided on an electronic device of thepayer. In some cases, the list is provided on a graphical user interfaceof the electronic device. The reward can be provided in the list.

The reward can be provided to the payer based on the payer's historywith the merchant. For example, a repeat payer (or customer) of amerchant can be provided a discount on select purchases that isdifferent from a first-time customer. Systems of the disclosure can beprogrammed to maintain a record of rewards, which rewards may beprovided to payers. For example a first-time payer of a merchant may beprovided a discount on a given purchase. The discount may be provided toincentivize the payer to purchase products or services from themerchant.

FIG. 1 schematically illustrates a method for facilitating a transactionbetween a payer and a merchant. The method can be implemented by acomputer system of the disclosure, such as the server 401 of FIG. 4. Ina first operation 101, one or more merchants that are at or in proximityto the payer are identified. Next, in a second operation 102, thecomputer system makes an inference of intent of the payer to conduct atransaction with each merchant. The inference of intent can involvedetermining the likelihood that the payer will conduct a transactionwith each merchant among the one or more merchants. Next, in a thirdoperation 103, the computer system provides the payer a reward or storedvalue based on the intent inferred in the second operation 102. Thereward can be directed to a merchant among the one or more merchants.The reward or reminder of stored value can be, for example, intended toincrease the likelihood that the payer will conduct a transaction withthe merchant. Next, in a fourth operation 104, the computer systemprocesses the transaction between the payer and the merchant. The rewardor stored value can be applied to the transaction during processing. Asan alternative, the reward can be provided by the computer system foruse in a future transaction.

Some embodiments provide a computer-implemented method for providing areward to a payer in connection with a transaction between the payer anda merchant, comprising processing, with the aid of a processor of acomputer system programmed to facilitate a transaction between a payerand the merchant, the transaction between the payer and the merchant.The transaction can be initiated upon the computer system receiving arequest from the payer to conduct the transaction with the merchant. Therequest can be received upon the computer system providing the payer areward to apply to the transaction or a future transaction. The rewardcan be provided to the payer based on an inference of intent of thepayer to conduct a transaction with the merchant. In some cases, thetransaction can be processed with a reward applied to the transaction.

The inference of intent can be calculated based upon payer-specificinformation maintained in a database of the computer system. Thepayer-specific information can be selected form a payer history. Thepayer-specific information can include one or more of a travel historyof the payer, a work history of the payer, an educational history of thepayer, a health history of the payer, a consumption history of thepayer, a transactional (e.g., spending) history of the payer, and socialengagement(s) history of the payer. The payer-specific information canbe used to calculate the likelihood that the payer will conduct atransaction with the merchant.

In some cases, the computer system identifies one or more merchants thatare at or in proximity to the geolocation of the payer. The computersystem can then access the database in order to identify a reward orstored value that can be used by the payer. The computer system canapply the reward or stored value to the transaction, or make the rewardor stored value available for use in a future transaction, if the payerproceeds to conduct the transaction with the merchant.

The status of the reward or stored value (e.g., used, available for use)can be displayed on the electronic device of the payer. The status canbe displayed on the UI, such as the GUI, of the electronic device. Thestatus of the reward or stored value can include a time period that isleft for the reward or stored value to be redeemed or otherwise appliedto a transaction. In some examples, the status can be presented based onthe record (or history) of one or more transactions between the payerand the merchant, which can be displayed against a milestone that mustbe met for the payer to be provided a reward from the merchant. Forexample, the GUI of the electronic device of the payer can show anelectronic punch card, as described elsewhere herein.

The computer system can maintain a record of payer transactions with agiven merchant. Rewards can be provided on the basis of the payer'shistory with the merchant. Alternatively, the system can maintain arecord of payer transactions with a given type of merchant.Rewards-based benefits can be provided on the basis of the payer'shistory with merchants that are included with the given type ofmerchant. For example, the payer can be provided certain benefits forbuying products from coffee stores or specific merchants, such as, e.g.,Starbucks®. Such benefits can be provided by the system.

Some embodiments provide a computer-implemented method for processing atransaction between a payer and a merchant. The method can beimplemented using computer systems of the disclosure, such as the server401 of FIG. 4. The method comprises inferring, with the aid of acomputer processor (also “processor” herein) of a computer system,intent of the payer to conduct a transaction with the merchant among oneor merchants at or in proximity to a geolocation of the payer. Theintent can be used to provide the payer a reward to be applied to atransaction with the merchant or another merchant. In an example, if thecomputer system determines that the payer is more likely to conduct atransaction with the merchant than other merchants that are at or inproximity to the payer, then the computer system offers the payer areward to apply to a transaction between the payer and the merchant. Thetransaction between the payer and the merchant can be processed with thereward applied to the transaction. As an alternative, the reward can beprovided to the payer for use in a future transaction and made availableto the payer in the future transaction, such as with the merchant oranother merchant.

A reward can be provided based on a determination of likelihood of apayer to conduct a transaction with a merchant. A computer-implementedmethod for facilitating a transaction between a payer and a merchant cancomprise providing the payer a reward to apply to a transaction with themerchant or a future transaction with the merchant or another merchant.The reward can be provided based on a determination, with the aid of oneor more processors of a computer system, of the likelihood of the payerto conduct a transaction with the merchant among one or merchants at orin proximity to a geolocation of the payer. The transaction between thepayer and the merchant can be processed with the aid of the computersystem subsequent to the payer being provided the reward.

Rewards can be selected by the system or by the merchant. For example,the merchant can specify one or more items or services that can be usedas rewards to provide (e.g., offer) a payer. As an alternative, amerchant can provide the system a reward to offer a payer. The merchantcan also select different rewards for different payers. For example, themerchant may wish to provide repeat payers a first reward (e.g., drinkdiscount) and first-time payers a second reward (e.g., free drink). Themerchant may also want to target a given payer based on specific items apayer may be interested in. For instance, a reward can be targeted toonly payers interested in buying televisions. Rewards can be targeted toonly particular item purchases, or groups of items purchased (e.g.,product bundles).

Various types of rewards can be provided by a merchant or the system tobe used by the payer in the transaction with the merchant. The types ofrewards can be dynamically selected in view of merchant preferences orrelevance criteria. Relevance criteria can include proximity of thepayer to the merchant, whether the payer is a first-time customer or arepeat customer, whether a payer has indicated on a list (e.g., productlist) that they are looking for a particular item, and factors relatedto the payer's history and preferences. A merchant can provide variousrewards, such as a free item or service, a discounted item or service,or a percentage reduction of a given transaction. Rewards may be subjectto merchant control. The system can provide a reward, which can be basedon the merchant's type of business, items and/or services offered forpurchase by the merchant, and/or payer-specific information (e.g., itemspurchased by the payer, the payer's age or sex, etc.).

A reward can be tailored to a merchant (i.e., merchant-specific). Afirst merchant of a given type (e.g., coffee store) can have a differentreward than a second merchant of the given type. In an example, a rewardfor a first coffee store can be a free cup of coffee, while a reward fora second coffee store can be a discount on a pastry.

FIG. 2 schematically illustrates a method (or workflow) for facilitatinga transaction between a payer and a merchant, in accordance with anembodiment of the invention. The method is implemented upon thecommunication between an electronic device of the payer, a computerserver (“Server”), and an electronic device of the merchant. The payer'sclient (“Payer Client”) can be an electronic device, such as a portableelectronic device, that is configured to communicate with the Server.The merchant's client (“Merchant Client”) can be a computer system thatis configured to communicate with the Server. The computer system caninclude one or more computers, each of which can include one or moreprocessors for executing machine-readable code to implement atransaction.

Initially, the geolocation of the Payer Client is determined, which maybe the geolocation of the payer. The geolocation of the payer can bedetermined using the electronic device of the payer, which can directgeolocation information to the Server. Next, the Server provides thePayer Client a list of merchants based on one or more geolocationcriteria of the payer, Server and/or the merchant. The Server mayprovide the Payer Client a list of merchants that are at or in proximityto the payer's geolocation.

The Server can also provide the payer a reward or a reminder of storedvalue that the payer can apply to a transaction between a merchant fromthe list, or to apply to a future transaction with the merchant oranother merchant, which may or may not be on the list. The reward can bean offer for a product or service discount, or a free product orservice, such as from the merchant. The reward and indication of storedvalue can be provided based on an inference of intent of the payer toconduct a transaction with a merchant on the list, which intent can beinferred by the Server, as described elsewhere herein.

Next, the payer requests to initiate a transaction with a given merchantfrom the list of merchants. In some cases, the payer may wish to “open atab” for the payer with the merchant, allowing the merchant to process atransaction that is charged to the payer's account. Upon the payerindicating in the Payer Client that the payer wishes to open a tab withthe merchant, the Payer Client directs the request to open the tab tothe Server. The Payer Client can transmit to the Server an indication toopen a tab associated with an account of the payer, reflecting anindication of the payer's consent to perform a cardless paymenttransaction with the merchant. Although the payer has requested to opena tab with the merchant, the payer can request to open a tab with othermerchant—i.e., the payer can request to open multiple tabs with multiplemerchants.

With reference to FIG. 2, The Merchant Client can send a request to theServer for a list of open tabs (e.g., a list of payer accounts fromwhich the Server has received indication of consent to enter into acardless payment transaction). The Server can then provide the MerchantClient a list of open tabs along with reward data or data reflectedstored value associated with the payer. The Merchant Client can thenrequest to process the transaction with the payer by processing apayment with the payer. The reward or stored value may be applied to thepayment. Alternatively, the reward may be provided to the payer for usein a future transaction with the merchant (e.g., a free or discountedcoffee in a future transaction with the merchant).

The transaction can be processed by the Server. The Merchant Client canprovide the Server an indication to close the tab associated with thetransaction. The indication can be provided prior to the Servercompleting the processing of the transaction, concurrently with theprocessing, or after the processing. The Server can then transmit anelectronic receipt to the payer, which can include any rewardsinformation, status of stored value, and/or loyalty updates (e.g.,electronic punch card updates). The workflow of FIG. 2 can be suited forcardless payment transactions.

In some cases, upon the Merchant Client requesting a list of open tabsfrom the Server (e.g., a list of payers from which the Server hasreceived indication of consent to enter into a payment transaction forthe merchant), the Merchant Client can request information relating towhether any of the tabs have unused rewards or stored value. The unusedrewards may have been provided to the payer from a previous transaction,such as a previous transaction with the merchant or another merchant.The unused rewards may have been provided to the payer based on aninference of intent for the payer to conduct a transaction with amerchant.

Next, the Server can determine whether the open tab account associatedwith the payer has any unused rewards or stored value with the merchant.As an alternative, such determination can be made at the MerchantClient. For instance, the Server can include a rewards database thatincludes payer transactional data and a rewards history. The Server canupdate the payer's rewards history based on one or more rewards criteriasupplied by the merchant, which criteria can include a free ordiscounted product or service upon a given number of purchases at themerchant (e.g., the payer shall receive one free drink upon purchasingten drinks), or the proximity of the payer to the merchant. In somecases, upon the payer requesting to open a tab with the merchant topurchase a product or service provided by the merchant, the Server orthe merchant can determine whether the payer is eligible to use a rewardin the transaction. If the payer is eligible to use a reward, themerchant can process payment with the reward applied and providestransaction information (e.g., payment and reward applied) to the Serverfor further processing. The Merchant Client can then provideinstructions to the Server to close the tab associated with the payer.The Server can then direct or otherwise provide an electronic receipt tothe Payer Client.

In some embodiments, a merchant can determine whether a payer has avalid reward or stored value prior to applying any reward or storedvalue to a transaction. In some cases, the Merchant Client directs aunique identification code or number, or other identifier that isuniquely associated with the payer, to the Server. The Server thendetermines whether the payer has a valid reward or stored value andtransmits to the Merchant Client an indication that the payer's rewardis valid or invalid, or, in some cases, provides the Merchant Client avalid reward associated with the payer. The Merchant Client can processpayment with reward or stored value applied to the transaction, andsubsequently transmit the transaction information to the Server.

The workflow of FIG. 2 can be implemented in cash or card transactions,or cardless transactions. Cardless transactions can include transactionsfacilitated with the aid of systems provided herein, such as the system400 of FIG. 4. In an example, in a cardless scenario a serverfacilitating a transaction between a payer and merchant, such as theserver 401 of FIG. 4, provides funds to the merchant and receive fundsfrom the payer.

In some examples, the Merchant Client can request reward or stored valueinformation from the Server, and the Server can provide that informationto the Merchant Client. The Merchant Client can then determine whetherthe payer has rewards or stored value to be applied to the transaction.

In some cases, the payer and merchant can maintain a record oftransactions. Such record can be maintained in a database of the Serveror a system in communication with the Server. The record can be used todetermine whether rewards or stored values can be applied to a giventransaction. In some examples, upon the Merchant Client processing apayment with the Server for a given transaction with the Payer Client ofthe payer, a rewards record or record of stored value of the payer isupdated to reflect the transaction. The rewards record can be spendingbased, visit based, etc. In some cases, the rewards record is anelectronic punch card, and upon the Server processing payment, therewards record is updated by including an additional electronic punch inthe punch card. The record can be updated by the Merchant Client, whichcan subsequently direct an indication of the updated rewards card to theServer, or, alternatively, the rewards record can be updated by theServer.

A reward or stored value can be selected by a merchant. For example, amerchant can select a product or service to offer a payer upon the payermeeting a milestone, such as a number of product purchases. Themilestone can be selected by the merchant.

A rewards record or stored value record can be created, updated orotherwise maintained in a database of the Server, such as for example,the storage unit 415 of the server 401 of FIG. 4. Alternatively, thedatabase can be located on the Merchant Client, or a system associatedwith the Merchant Client. In an example, a stored value record caninclude one or more columns indicating an initial stored value, valuesapplied/used in transactions, and a current balance. In an example, arewards record can include a database column that includes a requisitelimit (or milestone) that a payer must meet in order for the payer to beprovided a reward. The rewards record can also include a database columnthat includes a reward number that is incremented upon successivepurchases. Upon request from the Merchant Client, the Server can comparethe reward number to the limit to determine whether a reward may beprovided to the payer. In some cases, a rewards record is updated onlyif one or more rewards criteria (e.g., minimum spending amount) are met.The one or more rewards criteria may be selected by the merchant.

A rewards record can be an electronic punch card, which punch card cankeep a record of the number of transactions conducted that meet one ormore rewards criteria, and a requisite milestone that must be met inorder for the payer to be given a reward.

In some cases, upon the Server processing a transaction between amerchant and a payer, the Server provides the Payer Client an electronicreceipt of the transaction and an update on any rewards or stored valuethe payer may have with the merchant. The electronic receipt can beprovided to the payer via an electronic message, such as instantmessage, short-message service (SMS) text message, multimedia messageservice (MMS) text message, or electronic mail (“email”), or a messageor other notification that is specific to the application implementingthe transaction on the Payer Client (e.g., a device application, or“app”). In some cases, GUI of an electronic device of the payer can beupdated with information to reflect the transaction. In some situations,a merchant card on a GUI of the payer (or user) is updated to reflectthe transaction, to provide a reward status (e.g., product or servicediscount), or both.

The Server can facilitate payment from the payer to the merchant. In anexample, the system transfers funds to the merchant and receives fundsfrom the payer. The funds received from the payer may be greater than orequal to the funds transferred to the merchant. In another example, thesystem transfers funds directly from the payer to the merchant.

Merchant Directories and Merchants Cards

This disclosure provides merchant cards, which can be displayed on auser interface, such as a graphical user interface (GUI), on anelectronic device of a payer. Merchant cards can be displayed in adirectory. The directory can be provided on a GUI of an electronicdevice of the payer. The device can be coupled to a system having acomputer processor that is programmed or otherwise configured to executemachine-executable code to search for and provide merchants to theelectronic device of the payer, as described elsewhere herein.

A merchant card can be dedicated to a given merchant. In an example, afirst merchant card is dedicated to a first merchant and a secondmerchant card is dedicated to a second merchant that is different fromthe first merchant. The first merchant card can have information that isonly relevant to the first merchant and the second merchant card canhave information that is only relevant to the second merchant. There canbe a one-to-one correspondence between a merchant card and a merchant,though in some cases a merchant card can be dedicated to a plurality ofmerchants, such as a group of merchants.

A merchant card can permit a payer to initiate and conduct an electronictransaction with a merchant associated with the merchant card. Theelectronic transaction can be conducted over a network, such as theInternet or an intranet. In some examples, a merchant card permits apayer to open a tab with a merchant. The merchant card can permit apayer to initiate a transaction with a merchant.

The directory can be continually updated based on the location of thepayer, which may be changing. The directory can be updated to providemerchant cards associated with merchants that are within a givendistance from the payer (e.g., within 1, 2, 3, 4, or 5 miles from thepayer), closest to the payer (e.g., within 1 mile from the payer),deemed most relevant to the payer, or closest to the payer and mostrelevant. In some examples, a merchant card in the directory isassociated with a merchant that is within a distance that is selected bythe merchant. The merchant in such a case may wish to conduct atransaction with the payer if the payer is within a distance from themerchant that is selected by the merchant. In some cases, the system canpresent the payer with merchant cards of merchants that may not be theclosest to the payer, but may be more relevant to the payer thanmerchants that may be closer to the payer. In some cases, the directoryis updated every 1 second or less, 2 seconds or less, 3 seconds or less,4 seconds or less, 5 seconds or less, 6 seconds or less, 7 seconds orless, 8 seconds or less, 9 seconds or less, 10 seconds or less, 30seconds or less, 1 minute or less, 2 minutes or less, 3 minutes or less,4 minutes or less, 5 minutes or less, 10 minutes or less. Alternatively,the directory can be updated manually, such as upon request by thepayer. The directory can be updated in response to an event, such as,e.g., request by the payer, request by a merchant, a new promotion, or achanged location of the payer.

Geographic information of the payer, such as geographic location of thepayer, can be determined prior to providing the directory. The contentof the directory can be based on a geographic location of the payer. Insome cases, the one or more merchant cards are sorted based on theproximity of each merchant associated with each of the one or moremerchant cards to the geographic location of the payer. The one or moremerchant cards can be sorted based on a calculated likelihood that thepayer will conduct a transaction with a given merchant in the directory.For example, the merchant cards can be sorted in order of decreasinglikelihood that the payer will conduct a transaction with a givenmerchant. In some cases, the one or more merchant cards can be sortedbased on proximity of the payer to a given merchant and likelihood thatthe payer will conduct a transaction with the given merchant in thedirectory.

The geographic information of the payer can be determined with the aidof a geolocation device of the payer, which may be a portable electronicdevice. The geolocation device of the payer can be used to initiate andconduct a transaction with the merchant. The geolocation device can havea graphical user interface (GUI) that enables the payer to initiate thetransaction with a merchant and process the transaction.

The directory can be sorted based on the relevance of each merchantassociated with each of the one or merchant cards to the payer. Therelevance of each merchant to the payer can be determined based on oneor more relevance criteria, such as, for example, the inference ofintent that the payer will conduct a transaction with each merchant. Insome examples, the directory is sorted based on the likelihood that thepayer will conduct a transaction with each merchant. In an example, thesystem determines that the payer is more likely to conduct a transactionwith a first merchant than a second merchant, and displays a merchantcard of the first merchant above a merchant card of the second merchant.

Merchant cards can be sorted based on one or more relevance criteria,including inferred intent to conduct a transaction with a merchant, thenumber of transactions between the payer and a merchant, number oftransactions between the payer and a type of merchant, number oftransactions between the payer and all merchants, traffic conditions tothe one or more merchants, deals or promotions provided by the one ormore merchants, the degree (or level) of interest for a particularmerchant (e.g., The Coffee Spot) or particular type of merchant (e.g., acoffee shop, Indian food) from the payer's transaction history, type oftransaction involved, items involved in a transaction, types ofmerchants, quality of clicks on the merchant (e.g., click or finger tapon merchant card), content provided by merchant (e.g., quality ofimages), or other intelligence about payer behavior and/or merchantabilities to fulfill a payer's perceived need(s). In some cases, the oneor more relevance criteria include the distance of the payer from amerchant, such as the proximity of the payer to the merchant. In othercases, the one or more relevance criteria do not include the distance ofthe payer from a merchant. Relevance criteria can also include externaldata (e.g., weather, news, time of day, week, traffic conditions, etc.).Relevance criteria can include payer predictive behavioral spending,which may be a function of payer spending patterns over time. In somecases, the one or more relevance criteria include the distance of thepayer from a merchant, such as the proximity of the payer to themerchant. In other cases, the one or more relevance criteria do notinclude the distance of the payer from a merchant.

The directory can be filtered. In some examples, the directory isfiltered based on one or more criteria selected by the payer. Suchcriteria can include location, distance of a merchant associated with amerchant card from the payer, type of merchant (e.g., restaurant,grocery store), type of items offered by a merchant (e.g., coffee), hotor trendy items, hot or trendy merchants, new items and merchants.

In some embodiments, merchant cards in the directory are ranked orotherwise sorted in view of the payer's preferences, such as the payer'smerchant preferences (e.g., restaurant preferences), interests, itempreferences, list of items and/or merchants the payer has created and/orother factors that may be relevant. For example, if the systemdetermines that the payer visits coffee shops on a given day of the weekor a given time of the day, the payer can rank coffee merchants higherin the directory than merchants that do not provide coffee.

Merchant card ranking can be based on one or more relevance factors, or,in some examples, the combination of one or more relevance factors andthe payer's geolocation information, such as the payer's geographiclocation. Merchant cards can be ranked on the basis of a one or morerelevance factors that are weighted in view of the payer's proximity tomerchants. In an example, a weighted relevance ranking may be obtainedby multiplying a merchant's relevance, as may be determined based on oneor more relevance criteria, by a factor that is inversely proportionalto the payer's proximity to the merchant. Merchant cards may then beranked and provided for display by the payer based on the weightedrelevance ranking of each merchant card.

A merchant card can be selected to provide additional details on a givenmerchant, such as product or service details, costs associated withproducts and/or services of the merchant, the location of the merchant,directions to the merchant, hours of operation of the merchant, andpromotions offered by the merchant. The payer may select to open a tabwith the merchant to initiate a process to purchase a product or servicefrom the merchant.

In some examples, a directory can include 1 or more, 2 or more, 3 ormore, 4 or more, 5 or more, 10 or more, 20 or more, 30 or more, 40 ormore, 50 or more, 100 or more, or 1000 or more merchant cards.

A subset (e.g., some, nearly all) of the merchant cards can be renderedto be visually different than a remainder of the merchant cards. Suchrendering can be dynamic, such as with changing location or time. Suchrendering can be dynamic based on relevance to the payer. For example,among a first merchant card and second merchant card, the first merchantcard that is directed to a merchant that is more relevant to the payercan have a look that is more pleasing to the payer than the secondmerchant card. In some examples, the subset of merchant cards can berendered to have one or more different shapes and/or one or moredifferent colors than the remainder of the merchant cards. As analternative, or in addition to, the one or more different colors, othervisual indicators may be used, such as a background image or shading.The subset of merchant cards can be visually rendered to be differentthan the remainder based on one or more relevance criteria.

For example, a first merchant card can have a bright orange color andthe remainder of merchant cards can have a light gray color. The colorcan be the background color, a border color, or both. This can permit apayer to readily distinguish the first merchant card from the remainder.As another example, the first merchant card can be rectangular and havea size that is larger than the sizes of the remainder of the merchantcards.

FIG. 3 shows a merchant directory 300. The directory 300 can be providedon a GUI of an electronic device of the payer. The device may be coupledto a system having a processor that is configured to executemachine-executable code to search for and provide merchants to theelectronic device of the payer.

With continued reference to FIG. 3, the directory 300 includes a firstmerchant card 301, second merchant card 302, third merchant card 303 andfourth merchant card 304. The first card 301 is dedicated to a firstmerchant, the second card 302 is dedicated to a second merchant, thethird card 303 is dedicated to a third merchant, and the fourth card 304is dedicated to a fourth merchant. Each merchant card may be rendered onthe GUI for display on the electronic device of the payer. The firstmerchant may be a featured merchant. In some cases, the featuredmerchant is determined by the system or the electronic device of thepayer to be most relevant to the payer.

The second merchant card 302 includes a widget 305 with content that isdynamically tailored or otherwise generated to include a reward orinformation of stored value that can be based on an inference of intentof the payer to conduct a transaction with the second merchant. In somecases, the content of the widget 305 can be dynamically tailored orotherwise generated in view of one or more relevance criteria, asdescribed elsewhere herein. The widget can provide merchant deals,promotions, stored value usable at the merchant or other rewards thatare specific to the payer. For example, the widget can provide the payera discount at a given merchant (e.g., “50% off at The Coffee Spot”),which discount is provided on a predetermined condition (e.g., the basisthat the payer is a repeat customer of the merchant).

The payer can select any of the cards 301-304 to view addition detail oneach respective merchant. In addition, the payer can select any one ofthe cards 301-304 to purchase one or more products or services offeredby a merchant. Such products may include items of value to the payer,such as food items.

The merchant directory 300 provides various features that may beaccessible via payer gestures, as may be facilitated through the GUI onthe display of the electronic device of the payer. In some cases, thepayer can swipe a hand or finger of the payer or other pointing device(e.g., computer mouse, touch pen) across a surface of the display andadjacent to a card in the directory 300 to access additional featuresthat are specific to the card. For example, the payer can swipe a finger(e.g., from left to right) across the second card 302 to access a barthat enables the payer to open a tab at the second merchant, to select amerchant as a favorite merchant, to forward the merchant card (or a linkto the merchant) to a designated recipient, or to contact the merchant.The payer can swipe from left to right (or right to left) on a card (orwidget) to reveal content. Each card can reveal different content upon apayer swipe across the card. In some examples, the payer can swipe alonga first direction (e.g., top-to-bottom, bottom-to-top, diagonally frombottom to top, diagonally from top to bottom) to browse merchant cards,and swipe along a second direction that may be angled (e.g., orthogonal)to the first direction to view additional information about a givenmerchant. The payer can swipe diagonally across a given merchant card.

The cards 301-304 can be sorted based on the likelihood that the payerwill conduct a transaction with each merchant. In an example, a merchantthat the payer frequents may appear at the top of the list, whereas amerchant that the payer has never visited may appear at the bottom ofthe list.

In some cases, the payer indicates the cards or merchants that the payerprefers over other cards or merchants. For example, the payer can “like”or “dislike” (or, alternatively, not select “like”) a given merchant. Insome cases, the payer selecting to view a card, or the frequency withwhich the payer views cards, such as the frequency with which the payerflips through a cards in carousel view, can indicate a preference for acard. The system can learn, based on the payer's merchant or cardpreferences, which merchants the payer prefers, and provide the payerwith merchants that meet the payer's preferences. Such preferences maybe determined based on a profile of the payer, such as payer likes andpreferences, as may be provided in a profile of the payer.

The look and feel of a merchant card can be tailored based onpayer-specific merchant relevance criteria. In some embodiments, acomputer-implemented method for providing merchants to a payer comprisesproviding, on a graphical user interface (GUI) of an electronic deviceof the payer, a directory of merchant cards, each merchant card havinginformation of or related to a given merchant. Based on one or morepayer-specific merchant relevance criteria, a subset of the merchantcards are rendered to be visually different than a remainder of themerchant cards.

In some cases, the shape or color of one card may be selected to make itmore or less appealing to a payer than another card. Such modificationmay be made to increase the likelihood of the payer selecting one cardover another. For example, the second card 302 can be provided in acolor that is more appealing to the payer (based on the payer'spreferences) than the third card 303. Such modification may be made, forexample, if the payer is a repeat customer at the second merchant andnot the third merchant.

The directory 300 can be viewed in list view (as shown) or carouselview, in which the payer can review additional information about amerchant and peruse other merchants with the aid of gestures. The payermay elect to save certain merchant cards for future use or view. In someexamples, the system (or server) receives an indication from a payerselecting certain merchant cards, and in response, the system savescertain merchant cards for later view or use by the payer. In somecases, merchant cards can be ranked and displayed based on distance, orwhether merchants have recent offers or other promotional deals orincentives for the payer. If the payer is in close proximity to amerchant to make a payment, the merchant card may provide the payer theopportunity to make a payment (e.g., the card has an “open tab” widget),and may have information that is focused on enabling the payer to make apayment. In some examples, the system, upon determining the proximity ofthe payer to a merchant, provides the payer information that is focusedon enabling the payer to make a payment. If the payer is not in closeproximity to the merchant to make a payment, the merchant card candisplay dynamic information to give the payer a reason or incentive tovisit the merchant (e.g., “10% off your purchase”).

Systems for Facilitating Transactions

Another aspect of the disclosure provides a system that is programmed orotherwise configured to implement the methods of the disclosure. Thesystem can include a computer server that is operatively coupled to anelectronic device of a payer and an electronic device of a merchant.

FIG. 4 shows a system 400 programmed or otherwise configured to enable apayer to search for merchants, in accordance with an embodiment of theinvention. The system 400 includes a computer server (“server”) 401 thatis programmed to implement exemplary methods described herein. Theserver 401 includes a central processing unit (CPU, also “processor” and“computer processor” herein) 405, which can be a single core or multicore processor, or a plurality of processors for parallel processing.The server 401 also includes memory 410 (e.g., random-access memory,read-only memory, flash memory), electronic storage unit 415 (e.g., harddisk), communications interface 420 (e.g., network adapter) forcommunicating with one or more other systems, and peripheral devices425, such as cache, other memory, data storage and/or electronic displayadapters. The memory 410, storage unit 415, interface 420 and peripheraldevices 425 are in communication with the CPU 405 through acommunications bus (solid lines), such as a motherboard. The storageunit 415 can be a data storage unit (or data repository) for storingdata. The server 401 is operatively coupled to a computer network(“network”) 430 with the aid of the communications interface 420. Thenetwork 430 can be the Internet, an internet and/or extranet, or anintranet and/or extranet that is in communication with the Internet. Thenetwork 430 in some cases is a telecommunication and/or data network.The network 430 can include one or more computer servers, which canenable distributed computing, such as cloud computing. The network 430in some cases, with the aid of the server 401, can implement apeer-to-peer network, which may enable devices coupled to the server 401to behave as a client or a server.

The storage unit 415 can store files, such as filed related to merchantprofiles and/or accounts, and payer profiles. The storage unit 415 canstore payer data, e.g., payer preferences, payer context data and apayer history, including, without limitation, transactional history ofthe payer. The server 401 in some cases can include one or moreadditional data storage units that are external to the server 401, suchas located on a remote server that is in communication with the server401 through an intranet or the Internet.

The storage unit 415 can store payer and merchant transactionalinformation. The storage unit 415 can store payer transactionalinformation, which can include, without limitation, merchants from whichthe payer has purchased products and/or services, the number of timesthe payer has used a merchant, the frequency with which the payerpurchases products and/or services from a merchant, the types ofmerchants from which the payer purchases products and/or services. Thedata storage unit 415 can include payer stored value information (e.g.,gift cards, prepaid balances, etc.) and payer reward information, suchas rewards from merchants that the payer has accrued from previoustransactions with a merchant or multiple merchants.

The server 401 can communicate with one or more remote computer systemsthrough the network 430. In the illustrated example, the server 401 isin communication with a first computer system 435 and a second computersystem 440 that are located remotely with respect to the server 401. Inthe illustrated example, the first computer system 435 is a merchantcomputer system that may have a database for recording transaction data,and the second computer system 440 is a payer computer system, such as acomputer system of a potential purchaser of a service or product of themerchant. The first computer system 435 and second computer system 440can be, for example, personal computers (e.g., portable PC), slate ortablet PC's (e.g., Apple® iPad, Samsung® Galaxy Tab), telephones, Smartphones (e.g., Apple® iPhone, Android-enabled device, Blackberry®), orpersonal digital assistants.

In an example, the second computer system 440 is a portable electronicdevice of a payer that desires to search for and find merchants at or inproximity to a geolocation of the payer. The second computer system 440can be configured to provide geographic information of the payer,including the geolocation of the payer. The payer can access the server401 via the network 430 to request the search. The server 401 canconduct the search and transmit search results to the second computersystem 440 of the payer. The search results can be displayed on agraphical user interface of the second computer system 440. In somecases, both the first computer system 435 and the second computer system440 have a geolocation.

In some situations the system 400 includes a single server 401. In othersituations, the system 400 includes multiple servers in communicationwith one another through an intranet and/or the Internet.

The server 401 can be adapted to store payer profile information, suchas, for example, a name, physical address, email address, telephonenumber, instant messaging (IM) handle, educational information, workinformation, social likes and/or dislikes, products likes and/ordislikes, merchant preferences, favorites types of merchants (e.g.,restaurants preferred over bars) and historical information of pasttransactions of the payer (which may be transactions made using thesystem 400), and other information of potential relevance to the payeror other payers. Such profile information can be stored on the storageunit 415 of the server 401.

Methods as described herein can be implemented by way of machine (orcomputer processor) executable code (or software) stored on anelectronic storage location of the server 401, such as, for example, onthe memory 410 or electronic storage unit 415. During use, the code canbe executed by the processor 405. In some cases, the code can beretrieved from the storage unit 415 and stored on the memory 410 forready access by the processor 405. In some situations, the electronicstorage unit 415 can be precluded, and machine-executable instructionsare stored on memory 410. Alternatively, the code can be executed on thesecond computer system 440 of the payer.

The code can be pre-compiled and configured for use with a machine havea processer adapted to execute the code, or can be compiled duringruntime. The code can be supplied in a programming language that can beselected to enable the code to execute in a pre-compiled or as-compiledfashion.

The server 401 can be programmed to infer payer intent to conduct atransaction with a merchant, which can include calculating or otherwisedetermining the likelihood that the payer will conduct a transactionwith the merchant, as described elsewhere herein. The server 401 can usepayer history of the payer in such calculation. The server 401 caninclude various predictive models to enable the server to calculate thelikelihood that the payer will conduct a transaction with the merchant.

Aspects of the systems and methods provided herein, such as the server401, can be embodied in programming. Various aspects of the technologymay be thought of as “products” or “articles of manufacture” typicallyin the form of machine (or processor) executable code and/or associateddata that is carried on or embodied in a type of machine readablemedium. Machine-executable code can be stored on an electronic storageunit, such memory (e.g., read-only memory, random-access memory, flashmemory) or a hard disk. “Storage” type media can include any or all ofthe tangible memory of the computers, processors or the like, orassociated modules thereof, such as various semiconductor memories, tapedrives, disk drives and the like, which may provide non-transitorystorage at any time for the software programming. All or portions of thesoftware may at times be communicated through the Internet or variousother telecommunication networks. Such communications, for example, mayenable loading of the software from one computer or processor intoanother, for example, from a management server or host computer into thecomputer platform of an application server. Thus, another type of mediathat may bear the software elements includes optical, electrical andelectromagnetic waves, such as used across physical interfaces betweenlocal devices, through wired and optical landline networks and overvarious air-links. The physical elements that carry such waves, such aswired or wireless links, optical links or the like, also may beconsidered as media bearing the software. As used herein, unlessrestricted to non-transitory, tangible “storage” media, terms such ascomputer or machine “readable medium” refer to any medium thatparticipates in providing instructions to a processor for execution.

Hence, a machine readable medium, such as computer-executable code, maytake many forms, including but not limited to, a tangible storagemedium, a carrier wave medium or physical transmission medium.Non-volatile storage media include, for example, optical or magneticdisks, such as any of the storage devices in any computer(s) or thelike, such as may be used to implement the databases, etc. shown in thedrawings. Volatile storage media include dynamic memory, such as mainmemory of such a computer platform. Tangible transmission media includecoaxial cables; copper wire and fiber optics, including the wires thatcomprise a bus within a computer system. Carrier-wave transmission mediamay take the form of electric or electromagnetic signals, or acoustic orlight waves such as those generated during radio frequency (RF) andinfrared (IR) data communications. Common forms of computer-readablemedia therefore include for example: a floppy disk, a flexible disk,hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD orDVD-ROM, any other optical medium, punch cards paper tape, any otherphysical storage medium with patterns of holes, a RAM, a ROM, a PROM andEPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wavetransporting data or instructions, cables or links transporting such acarrier wave, or any other medium from which a computer may readprogramming code and/or data. Many of these forms of computer readablemedia may be involved in carrying one or more sequences of one or moreinstructions to a processor for execution.

The server 401 can be configured for data mining, extract, transform andload (ETL), or spidering (including Web Spidering where the systemretrieves data from remote systems over a network and access anApplication Programmer Interface or parses the resulting markup)operations, which may permit the system to load information from a rawdata source (or mined data) into a data warehouse. The data warehousemay be configured for use with a business intelligence system (e.g.,Microstrategy®, Business Objects®). The system can include a data miningmodule adapted to search for media content in various source locations,such as email accounts and various network sources, such as socialnetworking accounts (e.g., Facebook®, Foursquare®, Google+®, Linkedin®)or on publisher sites, such as, for example, weblogs.

The results of a payer-initiated search for merchants can be presentedto a payer on a user interface (UI), such as a graphical user interface(GUI), of an electronic device of the payer. A GUI can enable a payer toaccess the results of a search for merchants at a given geographic. TheUI, such as GUI, can be provided on a display of an electronic device ofthe payer that is adapted to provide geolocation information of thepayer, such as, for example, measure (or calculate) the geolocation ofthe payer. The display can be a capacitive or resistive touch display,or a head-mountable display (e.g., Google® Glasses). Such displays canbe used with other systems and methods of the disclosure.

Methods of the disclosure can be facilitated with the aid ofapplications (apps) that can be installed on electronic devices of apayer. An app can include a GUI on a display of the electronic device ofthe payer. The app can be programmed or otherwise configured to performcertain functions of the system, such as, for example, permitting apayer to initiate a transaction with a merchant if the payer is within agiven distance from the merchant. In an example, if the payer is withina given distance from the merchant, the app can permit the payer torequest to initiate a transaction with the merchant, which request isdirected to the system. The system can then inform the merchant that thepayer desires to initiate a transaction with the merchant, and thetransaction can be subsequently processed with the aid of the system, asdescribed elsewhere herein.

Systems of the disclosure may include both payer and merchant data. Thiscan permit a system to determine relevance ranking that may be payerspecific and directed at select one or more merchants or types ofmerchants. The system can be owned and/or operated by a single entity(e.g., company), or multiple entities.

In some cases, the merchant and/or payer information can be stored in amemory location (e.g., hard disk, flash memory) of the system.Accordingly, relevance ranking may be a function of both payer andmerchant information. For instance, a merchant may intend to targetpayers of a given age group. In some cases, a search for merchants by apayer may provide merchants that consider the payer to be relevant tothe merchants.

Examples

FIGS. 5-7 show example screenshots of graphical user interfaces (GUI's)of applications (apps) on display on an electronic device (e.g., mobiledevice) of a user (e.g., payer). The electronic device can include, forexample, a passive screen, a capacitive touch screen, or a resistivetouch screen. The electronic device can include a network interface anda browser that enables the user to access various sites or locations onan intranet or the Internet. The app is configured to enable the mobiledevice to communicate with a server, such as the server 401 of FIG. 4,which facilitates a transaction between the user and a merchant.

FIG. 5 shows example results of a search around a geolocation of apayer. The GUI includes, in list view (or “directory view”), a merchantcard and a featured merchant (“Coffee Spot”). The merchant cards for TheBakery Store and The Ice Cream Shop include widgets 501 and 502 thatinclude content dynamically tailored to the payer. The content of eachwidget 501 and 502 includes a discount or other promotion provided by amerchant relevant to the payer. The content of the widgets 501 and 502can be dynamically tailored based on an inference of intent of the payerto conduct a transaction with The Bakery Store and The Ice Cream Shop.In the illustrated example, The Bakery Store has offered the payer 10%off on the payer's first visit to The Bakery Store.

The merchant cards can be sorted on the basis of relevance criteria, asdescribed elsewhere herein. The cards of FIG. 5 can be ranked on thebasis of relevance to the payer, as determined, for example, based onhow frequently the payer visits a merchant. In the illustrated example,the system has determined that the payer is a first time payer at TheBakery Store and frequently purchases from The Ice Cream Shop. Thesystem provides The Bakery Store and The Ice Cream Store cards at thetop of the list in the illustrated directory. In some cases, relevancecan be determined on the basis of a single factor (e.g., the payer is afirst-time payer, the payer is a frequent payer), or a balance ofmultiple factors, such as proximity to a payer and whether the payer isa first time or frequent payer.

In some situations, merchant cards are ranked or otherwise sorted basedon what the system or a merchant considers being most relevant to thepayer. This can be based on an inference of intent of the payer toconduct a transaction with a merchant. For example, the system maymaintain a record of the payer's buying and spending habits, and withthe aid of a predictive model predict what the payer may need at a givenpoint in time. Merchant cards may then be sorted based on the predictivemodel. For example, the system may determine that the payer is likely towant a coffee over a pizza, and provide coffee shop merchant cardstowards the top of the list. In another example, the system provides thepayer a reward for a coffee purchase and no reward for a pizza purchase.

The payer can select a merchant card for more information on aparticular merchant. The payer can access a merchant card to view thelocation of the merchant. For example, the payer can select the CoffeeSpot merchant card to view the location of the Coffee Spot in map view,as shown in FIG. 6. The additional information on the Coffee Spot alsoincludes the address and phone number of the Coffee Spot, and adescription of the Coffee Spot (under “About”). The GUI of FIG. 6displays the distance of the Coffee Spot from the geolocation of thepayer (1.2 miles in the illustrated example), or the geolocation of thepayer. Under map view, the payer may zoom in for additional features andfunctionality, such as to view further details of a select area.

The payer can select a merchant card to view a reward or stored valueassociated with the merchant of the merchant card. FIG. 7 shows detailsof the reward or stored value associated with the Coffee Spot. In theillustrated example, the payer reward provides the payer “10% OFF APURCHASE” to be redeemed at a future point in time. The payer can redeema saved deal (or promotion) by selecting the deal from the GUI. The cardalso indicates that the payer is a regular (or repeat) customer at theCoffee Spot. From a merchant card, the payer may access one or moreproducts or services offered by a given merchant for purchase using thesystem.

Rewards and deals may have an expiration date that is set by the systemor the merchant. In some cases, a reward may not have an expirationdate. A merchant may authorize the system to provide a select number ofrewards or deals. In addition, saved rewards can be ranked and sortedbased on one or more relevance criteria, which may be dependent on thepayer's lifestyle factors, including spending habit. A most recentlysaved card may appear at the top of a list or other graphicalrepresentation (e.g., carousel view) of saved cards.

In some embodiments, saved cards can be ranked or otherwise sorted inview of the payer data, which can include payer history. Payer data caninclude the payer's eating habits, drinking habits, hobbies, exerciseroutines, sports activities, sleeping habits, work habits, habits ofsignificant others, and/or other factors that may be relevant to thepayer's lifestyle or living condition.

The payer can view cards by swiping a finger of the payer across adisplay of the electronic device of the payer either from top to bottomor bottom to top, depending on which cards the payer wishes to view. Amerchant card can be displayed in list view or carousel view. A merchantcard in carousel view may include additional information about themerchant and/or the payer that may not be provided in list view. In someexamples, in carousel view the payer can swipe along a first direction(e.g., top-to-bottom, bottom-to-top, diagonally from bottom to top,diagonally from top to bottom) to browse merchant cards, and swipe alonga second direction that may be angled (e.g., orthogonal) to the firstdirection to view additional information about a given merchant. Thepayer can swipe diagonally across a given merchant card. In some cases,swiping along the second direction can enable the payer to access otherfeatures and functionalities, such as accessing another carousel ormerchant directory. The reward card of FIG. 7 can be provided on the GUIin carousel view.

It should be understood from the foregoing that, while particularimplementations have been illustrated and described, variousmodifications can be made thereto and are contemplated herein. It isalso not intended that the invention be limited by the specific examplesprovided within the specification. While the invention has beendescribed with reference to the aforementioned specification, thedescriptions and illustrations of the preferable embodiments herein arenot meant to be construed in a limiting sense. Furthermore, it shall beunderstood that all aspects of the invention are not limited to thespecific depictions, configurations or relative proportions set forthherein which depend upon a variety of conditions and variables. Variousmodifications in form and detail of the embodiments of the inventionwill be apparent to a person skilled in the art. It is thereforecontemplated that the invention shall also cover any such modifications,variations and equivalents. It is intended that the following claimsdefine the scope of the invention and that methods and structures withinthe scope of these claims and their equivalents be covered thereby.

What is claimed is:
 1. A method comprising: sending, for display on amobile device, one or more merchant identifiers; receiving firstconfirmation that a user of the mobile device interacted with a merchantidentifier; determining proximity between the mobile device and amerchant device associated with the merchant identifier; and afterdetermining the proximity, sending, for display on the merchant device,a second confirmation that the user of the mobile device engaged withthe merchant identifier.
 2. The method of claim 1, wherein each of theone or more merchant identifiers identifies one merchant and at leastone merchant item offered by a corresponding merchant.
 3. The method ofclaim 1, wherein the first confirmation includes an interaction of theuser with the merchant identifier using the mobile device.
 4. The methodof claim 3, wherein the interaction includes adding a merchant itemoffered by a merchant associated with the merchant identifier to aproduct list of the user stored in a user profile.
 5. The method ofclaim 1, wherein the proximity between the mobile device and themerchant device is determined based on geographical location informationprovided by respective global positioning systems of the mobile deviceand the merchant device.
 6. The method of claim 1, further comprising:determining at least one reward for the user to use in purchasing anitem offered for sale by a merchant associated with the merchantidentifier, wherein the at least one reward is determined based at leastin part on the first confirmation.
 7. The method of claim 6, wherein thesecond confirmation includes the at least one reward to be applied tothe item offered for sale by the merchant when the user, using themobile device, completes a transaction with the merchant.
 8. Aprocessing system, comprising: one or more memories havingcomputer-readable instructions stored therein; and one or moreprocessors configured to execute the computer-readable instructions to:send, for display on a mobile application installed on a mobile device,one or more merchant identifiers; receive first confirmation that a userof the mobile device interacted with a merchant identifier; determineproximity between the mobile device and a merchant device associatedwith the merchant identifier; and after determining the proximity, send,for display on the merchant device, a second confirmation that the userof the mobile device engaged with the merchant identifier.
 9. Theprocessing system of claim 8, wherein each of the one or more merchantidentifiers identifies one merchant and at least one merchant itemoffered by a corresponding merchant.
 10. The processing system of claim8, wherein the first confirmation includes an interaction of the userwith the merchant identifier using the mobile application.
 11. Theprocessing system of claim 8, wherein the first confirmation isdetermined based on a predictive model developed by the processingsystem based on contextual and historical information on transactionsand user preferences of the user.
 12. The processing system of claim 10,wherein the first interaction includes adding a merchant item offered bya merchant associated with the merchant identifier to a product list ofthe user stored in a user profile on the mobile application.
 13. Theprocessing system of claim 8, wherein the proximity between the mobiledevice and the merchant device is determined based on geographicallocation information provided by respective global positioning systemsof the mobile device and the merchant device.
 14. The processing systemof claim 8, wherein the one or more processors are further configured toexecute the computer-readable instructions to determine at least onereward for the user to use in purchasing an item offered for sale by amerchant associated with the merchant identifier, wherein the at leastone reward is determined based at least in part on the firstconfirmation.
 15. The processing system of claim 14, wherein the secondconfirmation includes the at least one reward to be applied to the itemoffered for sale by the merchant when the user, using the mobile device,completes a transaction with the merchant.
 16. One or morenon-transitory computer-readable media comprising computer-readableinstructions, which when executed by one or more processors of aprocessing system, cause the processing system to: send, for display ona mobile application, one or more merchant identifiers; receive firstconfirmation that a user of the mobile application interacted with amerchant identifier; determine proximity between a mobile deviceexecuting the mobile application and a merchant device executing amerchant application associated with the merchant identifier; and afterdetermining the proximity, send, for display on the merchantapplication, a second confirmation that the user of the mobileapplication engaged with the merchant identifier.
 17. The one or morenon-transitory computer-readable media of claim 16, wherein each of theone or more merchant identifiers identifies one merchant and at leastone merchant item offered by a corresponding merchant.
 18. The one ormore non-transitory computer-readable media of claim 16, wherein thefirst confirmation includes an interaction of the user with the merchantidentifier using the mobile application.
 19. The one or morenon-transitory computer-readable media of claim 16, wherein the firstconfirmation is determined based on a predictive spending modeldeveloped by the processing system for the user based on contextual andhistorical information on transactions and user preferences of the user.20. The one or more non-transitory computer-readable media of claim 16,wherein the proximity between the mobile device and the merchant deviceis determined based on geographical location information provided byrespective global positioning systems of the mobile device and themerchant device.